Tracking area identifier (tai) change during authentication request processing

ABSTRACT

Methods, systems, and devices for wireless communications are described. A user equipment (UE) may receive a first authentication request in response to a first triggering request from the UE to a mobility management node of a first Tracking Area (TA) in which the UE is located. In some embodiments, the UE may prepare and store an authentication response according to the first authentication request. In response to determining that the UE has moved from the first TA to a second TA, the UE may abort a sending of the authentication response, and may send the stored authentication response according to the first authentication request to the mobility management node of the second TA in response to the receipt of the second authentication request and in further response to a determination that a given parameter of each of the first and second authentication requests are the same.

TECHNICAL FIELD

This application relates generally to wireless communication systems,and more specifically to properly processing an Authentication Requestat a user equipment (UE) responsive to a Tracking Area Identifier (TAI)change at the UE.

BACKGROUND

Wireless mobile communication technology uses various standards andprotocols to transmit data between a base station and a wireless mobiledevice. Wireless communication system standards and protocols caninclude the 3rd Generation Partnership Project (3GPP) long termevolution (LTE) (e.g., 4G) or new radio (NR) (e.g., 5G); the Instituteof Electrical and Electronics Engineers (IEEE) 802.16 standard, which iscommonly known to industry groups as worldwide interoperability formicrowave access (WiMAX); and the IEEE 802.11 standard for wirelesslocal area networks (WLAN), which is commonly known to industry groupsas Wi-Fi. In 3GPP radio access networks (RANs) in LTE systems, the basestation can include a RAN Node such as a Evolved Universal TerrestrialRadio Access Network (E-UTRAN) Node B (also commonly denoted as evolvedNode B, enhanced Node B, eNodeB, or eNB) and/or Radio Network Controller(RNC) in an E-UTRAN, which communicate with a wireless communicationdevice, known as user equipment (UE). In fifth generation (5G) wirelessRANs, RAN Nodes can include a 5G Node, NR node (also referred to as anext generation Node B or g Node B (gNB)).

RANs use a radio access technology (RAT) to communicate between the RANNode and UE. RANs can include global system for mobile communications(GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN),Universal Terrestrial Radio Access Network (UTRAN), and/or E-UTRAN,which provide access to communication services through a core network.Each of the RANs operates according to a specific 3GPP RAT. For example,the GERAN implements GSM and/or EDGE RAT, the UTRAN implements universalmobile telecommunication system (UMTS) RAT or other 3GPP RAT, theE-UTRAN implements LTE RAT, and NG-RAN implements 5G RAT. In certaindeployments, the E-UTRAN may also implement 5G RAT.

Frequency bands for 5G NR may be separated into two different frequencyranges. Frequency Range 1 (FR1) includes sub-6 GHz frequency bands, someof which are bands that may be used by previous standards, but maypotentially be extended to cover potential new spectrum offerings from410 MHz to 7125 MHz. Frequency Range 2 (FR2) includes frequency bandsfrom 24.25 GHz to 52.6 GHz. Bands in the millimeter wave (mm-Wave) rangeof FR2 have shorter range but higher available bandwidth than bands inthe FR1. Skilled persons will recognize these frequency ranges, whichare provided by way of example, may change from time to time or fromregion to region.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

To easily identify the discussion of any particular element or act, themost significant digit or digits in a reference number refer to thefigure number in which that element is first introduced.

FIG. 1 illustrates a flow diagram of messaging corresponding to raceconditions, according to some embodiments.

FIG. 2 illustrates a flow diagram of messaging corresponding to asolution to potential race conditions

FIG. 3 illustrates an example service based architecture in accordancewith certain embodiments.

FIG. 4 illustrates a UE in accordance with one embodiment.

FIG. 5 illustrates a network node in accordance with one embodiment.

DETAILED DESCRIPTION

In some network implementations using UEs being monitored in TrackingAreas (TAs), a Tracking Area Identifier (TAI) change at a UE (e.g., inresponse to a UE moving from one TA to another TA) may occur during aperiod when an Authentication Request from a mobility management node ofthe network is being processed by UE. Examples of a mobility managementnode may include, for example, a Mobility Management Entity (MME) of a4G LTE network, an Access and Mobility Management Function (AMF) of a 5Gnetwork, a combined UTRAN (comprising a Radio Network Controller(RNC)+NodeB) and Serving GPRS Support Node (SGSN) for Packet Switch (PS)domain and Mobile Switching Center (MSC) for Circuit Switch (CS) domainfor a 3G network, and a combined GERAN (comprising a Base TransceiverStation (BTS) and a Base Station Subsystem (BSC)) and SGSN for PS domainand MSC for CS domain in a 2G network.

This (or another) Authentication Request may have been triggered due to,for example, a Tracking Area Update (TAU) Request (e.g., in 4G LTE), aRouting Area Update (RAU) Request (e.g., in 2G, 3G) and/or aRegistration Request (e.g., in 5G) (among other examples). Such messages(triggering Authentication Requests the manner described) may bereferred to herein as “triggering requests.”

It may be that some systems/network implementations, a UE may beconfigured to send an Authentication Response every time the UE receivesa Authentication Request message from a mobility management node of thenetwork. However, there are scenarios (e.g., scenarios also involving aTAI change at the UE) where this requirement can cause the UE and thenetwork to go out of sync, resulting in that the UE is transitioned to alimited service mode. In some systems, it may be that the only way totransition the UE out of the limited service mode is by power cyclingthe UE (or, alternatively, to wait for a certain duration of time). Thismay be an undesired result in that it may impact the mobility one ormore (up to all) users of UEs of these systems, creating a perception ofa “bad” user experience generally.

One scenario causing this situation in the 4G LTE case (which uses TAUrequests to a mobility management node that is an MME) is describedbelow:

-   -   A UE may be camped on a first TA, TA1        -   The UE may send first TAU Request (e.g., a Combined TAU            Request) while in connected mode with an MME of TA1        -   A TAU Accept message with cause #17 is received at the UE in            response to the first TAU Request, which may have indicated            the failure of the first TAU Request        -   A T3411 timer is started in response to the failure of the            first TAU Request        -   The T3411 timer expires, and in response the UE sends a            second TAU Request while in connected mode with the MME of            TA1        -   Finally, a first Authentication Request is received at a            Mobile Equipment (ME) of the UE from the MME of TA1        -   The ME forwards the Authentication Request to a Universal            Subscriber Identity Module (USIM) of the UE    -   The UE then performs a cell change and enters connected mode on        a second TA, TA2        -   The UE aborts the ongoing TAU request (of TA1) and sends a            third (new) TAU request while in connected mode with an MME            of TA2        -   The ME of the UE receives an Authentication Response from            the USIM corresponding to the first Authentication Request            received from the MME of TA1 and sends this Authentication            Response message to network.        -   In some cases, prior to the receipt of the Authentication            Response, a second Authentication Request may be generated            by the MME of TA2 (perhaps with different authentication            vector parameters (e.g., random number (RAND) and/or            authentication token (AUTN) parameters) from the first            Authentication Request). In some embodiments, the            Authentication Request may also be sent to the UE. In these            cases, the MME of TA2 may send an Authentication Reject            message in response to the reception at the network of the            Authentication Response message corresponding to the first            Authentication Request. This may be because the MME of TA2            assumes that the Authentication Response message from the UE            (which corresponds to the first Authentication Request) was            supposed to be an Authentication Response for the            Authentication Request corresponding to TA2 as prepared by            the MME of TA2.        -   In other cases, the Authentication Response may be received            prior to the generation of any Authentication Request for            the UE by the MME of TA2. In these cases, the receipt of the            Authentication Response may also cause the MME of TA2 to            send the Authentication Reject message, because in this case            the MME of TA2 was not expecting an Authentication Response            from the UE.        -   In either case, the UE may remain camped on limited service            (due to the Authentication Reject message) until a power            cycle is performed. Note that the Authentication Reject            message may be properly received at the UE despite the            change from TA1 to TA2, since this change may not invalidate            a valid ciphering and/or integrity protection processes that            was previously established between the UE and the network.            Either of these cases may be referred to herein as a “race            condition.”

Scenarios implicating these concerns may include:

Scenario A

A UE in connected mode initiates a TAU Request due to change of:

-   -   When the UE changes the UE network capability information or the        MS network capability information or both;    -   When the UE changes the UE specific Discontinuous Reception        (DRX) parameter;    -   When the UE's usage setting or the voice domain preference for        E-UTRAN change in the UE    -   When the UE changes the UE specific DRX parameter;    -   When the UE changes the radio capability for GERAN, or cdma2000®        or both;    -   When the UE's usage setting or the voice domain preference for        E-UTRAN change in the UE;    -   When the UE needs to request the use of extended DRX (eDRX) or        needs to stop the use of eDRX;    -   When a change in the eDRX usage conditions at the UE requires        different extended DRX parameters;    -   When T3411 expires    -   Other potential triggers are contemplated.

The UE may be in connected mode, and one of the above triggers causes UEto initiate a TAU procedure. During this TAU procedure there is aconnected mode TAI change. The new TAI that UE detects in connected modemay not be in the registered TAI list. The UE may abort the ongoing TAURequest procedure, then send a new TAU Request integrity and cipheredprotected (as it is in connected mode with integrity and cipheringactive already) and waits for an Authentication Response from the USIM.In the meantime, the USIM sends the UE an Authentication Responsemessage corresponding to the original TAU procedure. As soon as theAuthentication Response (corresponding to the original TAU procedure) isreceived from USIM, the UE sends the Authentication Response to an MME.The MME determines that this Authentication Response message isincorrect and/or unexpected and sends an Authentication Reject messageintegrity+ciphered which is successfully decoded and processed by theUE. Accordingly, the UE may camp in limited service until it is powercycled.

Scenario B

A Normal TAU procedure (where a Normal TAU procedure is different from acombined TAU procedure, in that a Combined TAU procedure means bothCircuit Switched (CS) and Evolved Packed System (EPS) domainregistration is attempted, where as in Normal TAU, only EPS registrationis attempted) is triggered by UE due to the above triggers mentioned inScenario A. In this scenario, Normal TAU handling is similarlyapplicable to all the above scenarios as applicable for combined TAU.

Scenario C

Scenario C is a 5G scenario in CONNECTED mode. A UE in 5G NR triggers aRegistration Request with type “mobility and periodic registration” inCONNECTED mode. Triggers for the Registration Request in this case maybe any of the following:

-   -   T3511 expiry;    -   When the UE changes the 5GS Mobility Management (5GMM)        capability or the S1 UE network capability (or both);    -   When the UE's usage setting changes;    -   When the UE needs to change the slice(s) it is currently        registered to;    -   When the UE changes the UE specific DRX parameters;    -   When the UE needs to register for Short Message Service (SMS)        over Non-Access-Stratum (NAS), indicate a change in the        requirements to use SMS over NAS, or de-register from SMS over        NAS;    -   When the UE needs to indicate Protocol Data Unit (PDU) session        status to the network after performing a local release of PDU        session(s) as specified in 3GPP 24.501 section 6.4.1.5 and        6.4.3.5;    -   When the UE needs to request new Local Area Data Network (LADN)        information;    -   When the UE needs to request the use of eDRX, when a change in        the eDRX usage conditions at the UE requires different eDRX        parameters, or needs to stop the use of eDRX;    -   Other potential triggers are contemplated.

A Registration Request procedure may be ongoing, and the UE moves intoconnected mode for sending the Registration Request to the network.Ciphering and Integrity protection is not yet active, and the networksends an Authentication Request to the UE. The UE camps on a TAI whichis not part of the registration area (e.g., which is not registered aTAI list in LTE or a registered area in 5G). The UE may abort theongoing Registration Request procedure, while there is a pendingAuthentication Request response from the USIM. The UE triggers a newRegistration Request towards the AMF on the same RRC connection. Soonafterward, the Authentication Response corresponding to the originalRegistration Request is received from the USIM, the UE sends thisAuthentication Response to the network. The network determines that thisAuthentication Response is incorrect and/or unexpected and sends anAuthentication Reject message (which maybe integrity protected, causingUE to consider the Authentication Reject message as valid), causing theUE to be placed in limited service. If the Authentication Reject messageis sent with without integrity protection, then UE may bar the camped TAfor 30-60 mins and have no service for this duration.

In another aspect: when the Registration Request procedure is ongoingand the UE is in connected mode, and ciphering and integrity is active,the UE camps on a TAI which is not part of the registration area (e.g.,which is not registered a TAI list in LTE or a registered area in 5G).The UE then aborts the ongoing Registration Request procedure whilethere is a pending Authentication Request response from USIM. The UEtriggers a new Registration Request message towards the AMF. Soonafterward, the Authentication Response (corresponding to the originalRegistration Request procedure) is received from USIM and the UE sendsthis Authentication Response to the network. The AMF determines thatthis Authentication Response message is incorrect and/or unexpected, andsends an Authentication Reject message (integrity and cipheredprotected) which is successfully decoded and processed by the UE. Inresponse, the UE may camp in limited service until it is power cycled.

Scenario D

Scenario D is a 5G Scenario. The UE is in connected mode with integrityand ciphering active and the network triggers an Authentication Requestprocedure (the network can trigger the Authentication Request procedureat any time when UE is in connected mode). The UE then detects a changein camped TAI (which is not part of the registration area) while anAuthentication Response message from the USIM is awaited. The UEimmediately triggers a Registration Request with type “mobility andperiodic registration.” The Authentication Response corresponding to theoriginal Authentication Request procedure message is then received atthe UE from the USIM and is sent to the AMF on the new TAI just as theAMF triggers a new Authentication Request procedure on the new TAI. Oncethis Authentication Response message is received at the AMF, the AMFdetermines that it is incorrect and/or unexpected and sends anAuthentication Reject message integrity and ciphered protected which issuccessfully decoded and processed by the UE. In response, the UE maycamp in limited service until it is power cycled.

Scenario E

Scenario E is a 4G Scenario. The UE may be in connected mode withintegrity and ciphering active, and the network triggers anAuthentication Request procedure (the network can trigger anAuthentication Request procedure at any time when UE is in connectedmode). The UE then detects a change in camped TAI (which is not part ofthe registration TAI list) while an Authentication Response Message fromthe USIM is awaited. The UE immediately triggers a TAU Request message.The Authentication Response message corresponding to the originalAuthentication Request procedure is then received from the USIM is sentto the MME on the new TAI just as the MME triggers a new AuthenticationRequest message on the new TAI. Once this Authentication Responsemessage is received at the MME, the MME determines that it is incorrectand/or unexpected and sends an Authentication Reject message integrityand ciphered protected which is successfully decoded and processed bythe UE. In response, the UE may camp in limited service until it ispower cycled.

Scenario F

Analogous issues to those discussed above can happen in 2G & 3G as well.In these cases UE will initiate a Routing Area Request procedure and/ora Location Updating Request procedure, with analogous race scenariosbeing caused thereby.

It is contemplated that the above scenarios may occur even in caseswhere the mobility management node of TA1 and the mobility managementnode of TA2 are the same mobility management node.

In systems described above, there are multiple implementations possibleat both the UE and the network side to handle the scenarios describedabove which may result in erroneous handling in UE:

-   -   1. The network may retransmit the same Authentication Request        from the mobility management node of TA1 as was sent from the        mobility management node of TA2    -   2. The network can send a new Authentication Request from the        mobility management node of TA1    -   3. The UE may incorrectly send an Authentication Response for        the Authentication Request from the mobility management node of        TA1 according to TA1 instead of for the Authentication Request        from the mobility management node of TA2 according to TA2.

FIG. 1 illustrates a flow diagram 100 of messaging corresponding to raceconditions, according to some embodiments. A system as described hereinmay include a UE 102, an MME-TAC1 104 (which may be an MME of a firstTA, TA1, using a first Tracking Area Code (TAC), TAC1), and an MME-TAC2106 (which may be an MME of a second TA, TA2, using a second TAC, TAC2).The UE 102 may include a USIM 108 and a ME 110.

In block 112, the ME 110 of the UE 102 is in connected mode with theMME-TAC1 104, and both the UE 102 and the MME-TAC1 104 have a valid EPSsecurity context identified by a first Key Set Identifier (KSI), KSI-1.The UE 102 may initiate a first Combined TAU Request. This may be dueto, for example, a T3411 expiration in a case where a previous CombinedTAU Request was accepted with cause #17.

The ME 110 of the UE 102 may then send this first Combined TAU requestin the Combined TAU Request message 114 to the MME-TAC1 104. TheMME-TAC1 104 may send, in response, an Authentication Request message116 corresponding to the Combined TAU Request message 114. TheAuthentication Request message 116 may be according to a second KSI,KSI-2. The Authentication Request message 116 may be received at the ME110 of the UE 102.

The ME 110 may then forward the Authentication Request message 116message as the Authentication Request message 118 to the USIM 108.

In block 120, the ME 110 of the UE 102 makes a connected mode cellchange to an new TA corresponding to TAC2 and the MME-TAC2 106.

In block 122, the UE aborts the ongoing Combined TAU Request andre-initiates a new Combined TAU Request with the MME-TAC2 106. This maybe using the same Radio Resource Control (RRC) connection as was usedpreviously.

The ME 110 of the UE 102 may then send this new Combined TAU Request inthe Combined TAU Request message 124 to the MME-TAC2 106.

The USIM 108 may then send the Authentication Response message 126 tothe ME 110. This Authentication Response message 126 may correspond tothe Authentication Request message 118 that was forwarded from theMME-TAC1 104 to the USIM 108 by the ME 110. It may be that the UE 102did not abort the sending of this Authentication Response message 126 inresponse to the connected mode cell change to TAC2 of block 120.

After the Authentication Response message 126 is sent, the UE may returnto the TAC2 coverage area, and may camp in the TA corresponding to theTAC2 without a periodic timer expiry.

The ME 110 may then forward the Authentication Response message 126message to the MME-TAC2 106 as the Authentication Response message 128.

At or near this time period, the MME-TAC2 106 may have also prepared theAuthentication Request message 130. The Authentication Request message130 may be according to a third KSI, KSI-3.

Here, multiple problematic scenarios are possible. A first is that theAuthentication Response message 128 arrives at the MME-TAC2 106 prior tothe preparation of the Authentication Request message 130 by theMME-TAC2 106. In this case, the receipt of the Authentication Responsemessage 128 may cause the MME-TAC2 106 to send the Authentication Rejectmessage 134, because in this case the MME-TAC2 106 was not expecting theAuthentication Response message 128 from the UE.

A second of the problematic scenarios is that the Authentication Requestmessage 130 may have been generated (an perhaps, but not necessarily,sent) by the MME-TAC2 106 prior to the receipt of the AuthenticationResponse message 128. In these cases, it is possible that theAuthentication Request message 130 was generated with different RANDand/or AUTN parameters than the Authentication Request message 116. Inthis case, the MME-TAC2 106 may send the Authentication Reject message134 in response to the receipt of the Authentication Response message128, because the MME-TAC2 106 assumes that the Authentication Responsemessage 128 was supposed to be in response to the Authentication Requestmessage 130 (but it clearly is not because of the mismatch between theRAND and/or the AUTN parameters between the Authentication Responsemessage 128 and the Authentication Request message 130).

In either case, the MME-TAC2 106 prepares in block 132 an AuthenticationReject message. This message may be properly configured to be acceptedat the ME 110 of the 102 because the change from TA1 to TA2 may not haveinvalidated a valid ciphering and/or integrity protection processpreviously established between the UE and the network).

The MME-TAC2 106 may then send the Authentication Reject message 134 tothe ME 110 of the UE 102. In response, the UE 102, in block 136, maymark the USIM 108 as invalid for Circuit Switched (CS) and PacketSwitched (PS) service since the Authentication Reject message 134 isreceived integrity and ciphered protected in the expected manner. The UE102 may further camp on limited service on the same Public Land MobileNetwork (PLMN) after an RRC Connection release. The UE 102 may remain inthis state of reduced utility until the UE 102 is power cycled.

The race conditions identified above may be solved by the following:During an authentication procedure (e.g., one of the proceduresdiscussed previously) if a TAI change occurs that will result in a newtriggering request to be sent corresponding to a new TA, then the UE maynot send a Authentication Response message corresponding to anAuthentication Request of the original authentication procedure to themobility management node of the new TA (e.g., it may abort the sendingof such a message). Instead, the UE may compute this AuthenticationResponse message and store it in memory. The UE may then, after abortingthe previous authentication procedure, reinitiate the new authenticationprocedure with the mobility management node of TA2 and wait for a newAuthentication Request message from the network (e.g., from the mobilitymanagement node of TA2 according to TA2).

At this stage, if UE receives again the same Authentication Requestmessage (e.g., an Authentication Request message having the same RANDparameter as the first Authentication Request message corresponding tothe original authentication procedure), then UE may not send the newAuthentication Request message to a USIM for processing, but rather mayreply back with the Authentication Response message that is stored inmemory.

FIG. 2 illustrates a flow diagram 200 of messaging corresponding to asolution to potential race conditions, according to some embodiments.Elements 102-228 may be analogous to similarly numbered elements foundin FIG. 1.

One difference may be that the UE 202 has been configured to abort asending of the Authentication Response message 228 in response to theconnected mode cell change to TAC2, corresponding to the MME-TAC2 206 ofblock 220. Accordingly, it may be that the ME 210 is configured to abortthe sending of the Authentication Response message 228 corresponding tothe Authentication Response message 226 received form the USIM 208(e.g., it does not send the Authentication Response message 228 messageto the MME-TAC2 206). Further, the ME 210 at block 240 may store theAuthentication Response message 226 in volatile memory.

The ME 210 may then receive an Authentication Request message 242corresponding to the Combined TAU Request message 224. The ME 210 maydetermine whether the Authentication Request message 242 is the same asthe Authentication Request message 216. This may be done by checking theRAND parameters of the Authentication Request message 216 and theAuthentication Request message 242 to see whether they are the same.

If they are not the same, the ME 110 may forward the AuthenticationRequest message 242 to the USIM 208. The USIM 208 may then generate acorresponding Authentication Response message 246 send theAuthentication Response message 246 to the ME 210. The ME 210 may thenforward the Authentication Response message 246 to the MME-TAC2 206 asthe Authentication Response message 248.

Alternatively, if the RAND values are the same, the ME 210 may insteadbypass forwarding the Authentication Request message 244 to the USIM 208and pull the Authentication Response message 226 from the volatilememory (which was stored in block 240 as described above). In this case,it may be that in this case, the Authentication Response message 226stored in the volatile memory is a good response to the AuthenticationRequest message 242 from the MME-TAC2 206. Accordingly, the ME 210 mayforward the Authentication Response message 226 as the AuthenticationResponse message 248.

Example System Architecture

In certain embodiments, 5G System architecture supports dataconnectivity and services enabling deployments to use techniques such asNetwork Function Virtualization and Software Defined Networking. The 5GSystem architecture may leverage service-based interactions betweenControl Plane Network Functions. Separating User Plane functions fromthe Control Plane functions allows independent scalability, evolution,and flexible deployments (e.g., centralized location or distributed(remote) location). Modularized function design allows for functionre-use and may enable flexible and efficient network slicing. A NetworkFunction and its Network Function Services may interact with another NFand its Network Function Services directly or indirectly via a ServiceCommunication Proxy. Another intermediate function may help routeControl Plane messages. The architecture minimizes dependencies betweenthe AN and the CN. The architecture may include a converged core networkwith a common AN-CN interface that integrates different Access Types(e.g., 3GPP access and non-3GPP access). The architecture may alsosupport a unified authentication framework, stateless NFs where thecompute resource is decoupled from the storage resource, capabilityexposure, concurrent access to local and centralized services (tosupport low latency services and access to local data networks, UserPlane functions can be deployed close to the AN), and/or roaming withboth Home routed traffic as well as Local breakout traffic in thevisited PLMN.

The 5G architecture may be defined as service-based and the interactionbetween network functions may include a service-based representation,where network functions (e.g., AMF) within the Control Plane enableother authorized network functions to access their services. Theservice-based representation may also include point-to-point referencepoints. A reference point representation may also be used to show theinteractions between the NF services in the network functions describedby point-to-point reference point (e.g., N11) between any two networkfunctions (e.g., AMF and SMF).

FIG. 3 illustrates a service based architecture 300 in 5GS according toone embodiment. As described in 3GPP TS 23.501, the service basedarchitecture 300 comprises NFs such as an NSSF 302, a NEF 304, an NRF306, a PCF 308, a UDM 310, an AUSF 312, an AMF 314, an SMF 316, forcommunication with a UE 320, a (R)AN 322, a UPF 324, and a DN 326. TheNFs and NF services can communicate directly, referred to as DirectCommunication, or indirectly via a SCP 318, referred to as IndirectCommunication. FIG. 3 also shows corresponding service-based interfacesincluding Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf, andNausf, as well as reference points N1, N2, N3, N4, and N6. A few examplefunctions provided by the NFs shown in FIG. 3 are described below.

The NSSF 302 supports functionality such as: selecting the set ofNetwork Slice instances serving the UE; determining the Allowed NSSAIand, if needed, mapping to the Subscribed S-NSSAIs; determining theConfigured NSSAI and, if needed, the mapping to the Subscribed S-NSSAIs;and/or determining the AMF Set to be used to serve the UE, or, based onconfiguration, a list of candidate AMF(s), possibly by querying the NRF.

The NEF 304 supports exposure of capabilities and events. NFcapabilities and events may be securely exposed by the NEF 304 (e.g.,for 3rd party, Application Functions, and/or Edge Computing). The NEF304 may store/retrieve information as structured data using astandardized interface (Nudr) to a UDR. The NEF 304 may also secureprovision of information from an external application to 3GPP networkand may provide for the Application Functions to securely provideinformation to the 3GPP network (e.g., expected UE behavior, 5GLAN groupinformation, and service specific information), wherein the NEF 304 mayauthenticate and authorize and assist in throttling the ApplicationFunctions. The NEF 304 may provide translation of internal-externalinformation by translating between information exchanged with the AF andinformation exchanged with the internal network function. For example,the NEF 304 translates between an AF-Service-Identifier and internal 5GCore information such as DNN and S-NSSAI. The NEF 304 may handle maskingof network and user sensitive information to external AF's according tothe network policy. The NEF 304 may receive information from othernetwork functions (based on exposed capabilities of other networkfunctions), and stores the received information as structured data usinga standardized interface to a UDR. The stored information can beaccessed and re-exposed by the NEF 304 to other network functions andApplication Functions, and used for other purposes such as analytics.For external exposure of services related to specific UE(s), the NEF 304may reside in the HPLMN. Depending on operator agreements, the NEF 304in the HPLMN may have interface(s) with NF(s) in the VPLMN. When a UE iscapable of switching between EPC and 5GC, an SCEF+NEF may be used forservice exposure.

The NRF 306 supports service discovery function by receiving an NFDiscovery Request from an NF instance or SCP and providing theinformation of the discovered NF instances to the NF instance or SCP.The NRF 306 may also support P-CSCF discovery (specialized case of AFdiscovery by SMF), maintains the NF profile of available NF instancesand their supported services, and/or notify about newlyregistered/updated/deregistered NF instances along with its NF servicesto the subscribed NF service consumer or SCP. In the context of NetworkSlicing, based on network implementation, multiple NRFs can be deployedat different levels such as a PLMN level (the NRF is configured withinformation for the whole PLMN), a shared-slice level (the NRF isconfigured with information belonging to a set of Network Slices),and/or a slice-specific level (the NRF is configured with informationbelonging to an S-NSSAI). In the context of roaming, multiple NRFs maybe deployed in the different networks, wherein the NRF(s) in the VisitedPLMN (known as the vNRF) are configured with information for the visitedPLMN, and wherein the NRF(s) in the Home PLMN (known as the hNRF) areconfigured with information for the home PLMN, referenced by the vNRFvia an N27 interface.

The PCF 308 supports a unified policy framework to govern networkbehavior. The PCF 308 provides policy rules to Control Plane function(s)to enforce them. The PCF 308 accesses subscription information relevantfor policy decisions in a Unified Data Repository (UDR). The PCF 308 mayaccess the UDR located in the same PLMN as the PCF.

The UDM 310 supports generation of 3GPP AKA Authentication Credentials,User Identification Handling (e.g., storage and management of SUPI foreach subscriber in the 5G system), de-concealment of a privacy-protectedsubscription identifier (SUCI), access authorization based onsubscription data (e.g., roaming restrictions), UE's Serving NFRegistration Management (e.g., storing serving AMF for UE, storingserving SMF for UE's PDU Session), service/session continuity (e.g., bykeeping SMF/DNN assignment of ongoing sessions., MT-SMS delivery, LawfulIntercept Functionality (especially in outbound roaming cases where aUDM is the only point of contact for LI), subscription management, SMSmanagement, 5GLAN group management handling, and/or external parameterprovisioning (Expected UE Behavior parameters or Network Configurationparameters). To provide such functionality, the UDM 310 usessubscription data (including authentication data) that may be stored ina UDR, in which case a UDM implements the application logic and may notrequire an internal user data storage and several different UDMs mayserve the same user in different transactions. The UDM 310 may belocated in the HPLMN of the subscribers it serves, and may access theinformation of the UDR located in the same PLMN.

The AF 328 interacts with the Core Network to provide services that, forexample, support the following: application influence on trafficrouting; accessing the NEF 304; interacting with the Policy frameworkfor policy control; and/or IMS interactions with 5GC. Based on operatordeployment, Application Functions considered to be trusted by theoperator can be allowed to interact directly with relevant NetworkFunctions. Application Functions not allowed by the operator to accessdirectly the Network Functions may use the external exposure frameworkvia the NEF 304 to interact with relevant Network Functions.

The AUSF 312 supports authentication for 3GPP access and untrustednon-3GPP access. The AUSF 312 may also provide support for NetworkSlice-Specific Authentication and Authorization.

The AMF 314 supports termination of RAN CP interface (N2), terminationof NAS (N1) for NAS ciphering and integrity protection, registrationmanagement, connection management, reachability management, MobilityManagement, lawful intercept (for AMF events and interface to LISystem), transport for SM messages between UE and SMF, transparent proxyfor routing SM messages, Access Authentication, Access Authorization,transport for SMS messages between UE and SMSF, SEAF, Location Servicesmanagement for regulatory services, transport for Location Servicesmessages between UE and LMF as well as between RAN and LMF, EPS BearerID allocation for interworking with EPS, UE mobility event notification,Control Plane CIoT 5GS Optimization, User Plane CIoT 5GS Optimization,provisioning of external parameters (Expected UE Behavior parameters orNetwork Configuration parameters), and/or Network Slice-SpecificAuthentication and Authorization. Some or all of the AMF functionalitiesmay be supported in a single instance of the AMF 314. Regardless of thenumber of Network functions, in certain embodiments there is only oneNAS interface instance per access network between the UE and the CN,terminated at one of the Network functions that implements at least NASsecurity and Mobility Management. The AMF 314 may also include policyrelated functionalities.

In addition to the functionalities described above, the AMF 314 mayinclude the following functionality to support non-3GPP access networks:support of N2 interface with N3IWF/TNGF, over which some information(e.g., 3GPP Cell Identification) and procedures (e.g., Handover related)defined over 3GPP access may not apply, and non-3GPP access specificinformation may be applied that do not apply to 3GPP accesses; supportof NAS signaling with a UE over N3IWF/TNGF, wherein some proceduressupported by NAS signaling over 3GPP access may be not applicable tountrusted non-3GPP (e.g., Paging) access; support of authentication ofUEs connected over N3IWF/TNGF; management of mobility, authentication,and separate security context state(s) of a UE connected via a non-3GPPaccess or connected via a 3GPP access and a non-3GPP accesssimultaneously; support a coordinated RM management context valid over a3GPP access and a Non 3GPP access; and/or support dedicated CMmanagement contexts for the UE for connectivity over non-3GPP access.Not all of the above functionalities may be required to be supported inan instance of a Network Slice.

The SMF 316 supports Session Management (e.g., Session Establishment,modify and release, including tunnel maintain between UPF and AN node),UE IP address allocation & management (including optional Authorization)wherein the UE IP address may be received from a UPF or from an externaldata network, DHCPv4 (server and client) and DHCPv6 (server and client)functions, functionality to respond to Address Resolution Protocolrequests and/or IPv6 Neighbor Solicitation requests based on local cacheinformation for the Ethernet PDUs (e.g., the SMF responds to the ARPand/or the IPv6 Neighbor Solicitation Request by providing the MACaddress corresponding to the IP address sent in the request), selectionand control of User Plane functions including controlling the UPF toproxy ARP or IPv6 Neighbor Discovery or to forward all ARP/IPv6 NeighborSolicitation traffic to the SMF for Ethernet PDU Sessions, trafficsteering configuration at the UPF to route traffic to properdestinations, 5G VN group management (e.g., maintain the topology of theinvolved PSA UPFs, establish and release the N19 tunnels between PSAUPFs, configure traffic forwarding at UPF to apply local switching,and/or N6-based forwarding or N19-based forwarding), termination ofinterfaces towards Policy control functions, lawful intercept (for SMevents and interface to LI System), charging data collection and supportof charging interfaces, control and coordination of charging datacollection at the UPF, termination of SM parts of NAS messages, DownlinkData Notification, Initiator of AN specific SM information sent via AMFover N2 to AN, determination of SSC mode of a session, Control PlaneCIoT 5GS Optimization, header compression, acting as I-SMF indeployments where I-SMF can be inserted/removed/relocated, provisioningof external parameters (Expected UE Behavior parameters or NetworkConfiguration parameters), P-CSCF discovery for IMS services, roamingfunctionality (e.g., handle local enforcement to apply QoS SLAs (VPLMN),charging data collection and charging interface (VPLMN), and/or lawfulintercept (in VPLMN for SM events and interface to LI System),interaction with external DN for transport of signaling for PDU Sessionauthentication/authorization by external DN, and/or instructing UPF andNG-RAN to perform redundant transmission on N3/N9 interfaces. Some orall of the SMF functionalities may be supported in a single instance ofa SMF. However, in certain embodiments, not all of the functionalitiesare required to be supported in an instance of a Network Slice. Inaddition to the functionalities , the SMF 316 may include policy relatedfunctionalities.

The SCP 318 includes one or more of the following functionalities:Indirect Communication; Delegated Discovery; message forwarding androuting to destination NF/NF services; communication security (e.g.,authorization of the NF Service Consumer to access the NF ServiceProducer's API), load balancing, monitoring, overload control, etc.;and/or optionally interact with the UDR, to resolve the UDM Group ID/UDRGroup ID/AUSF Group ID/PCF Group ID/CHF Group ID/HSS Group ID based onUE identity (e.g., SUPI or IMPI/IMPU). Some or all of the SCPfunctionalities may be supported in a single instance of an SCP. Incertain embodiments, the SCP 318 may be deployed in a distributed mannerand/or more than one SCP can be present in the communication pathbetween NF Services. SCPs can be deployed at PLMN level, shared-slicelevel, and slice-specific level. It may be left to operator deploymentto ensure that SCPs can communicate with relevant NRFs.

The UE 320 may include a device with radio communication capabilities.For example, the UE 320 may comprise a smartphone (e.g., handheldtouchscreen mobile computing devices connectable to one or more cellularnetworks). The UE 320 may also comprise any mobile or non-mobilecomputing device, such as Personal Data Assistants (PDAs), pagers,laptop computers, desktop computers, wireless handsets, or any computingdevice including a wireless communications interface. A UE may also bereferred to as a client, mobile, mobile device, mobile terminal, userterminal, mobile unit, mobile station, mobile user, subscriber, user,remote station, access agent, user agent, receiver, radio equipment,reconfigurable radio equipment, or reconfigurable mobile device. The UE320 may comprise an IoT UE, which can comprise a network access layerdesigned for low-power IoT applications utilizing short-lived UEconnections. An IoT UE can utilize technologies (e.g., M2M, MTC, or mMTCtechnology) for exchanging data with an MTC server or device via a PLMN,other UEs using ProSe or D2D communications, sensor networks, or IoTnetworks. The M2M or MTC exchange of data may be a machine-initiatedexchange of data. An IoT network describes interconnecting IoT UEs,which may include uniquely identifiable embedded computing devices(within the Internet infrastructure). The IoT UEs may execute backgroundapplications (e.g., keep-alive messages, status updates, etc.) tofacilitate the connections of the IoT network.

The UE 320 may be configured to connect or communicatively couple withthe (R)AN 322 through a radio interface 330, which may be a physicalcommunication interface or layer configured to operate with cellularcommunication protocols such as a GSM protocol, a CDMA network protocol,a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, aUMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, andthe like. For example, the UE 320 and the (R)AN 322 may use a Uuinterface (e.g., an LTE-Uu interface) to exchange control plane data viaa protocol stack comprising a PHY layer, a MAC layer, an RLC layer, aPDCP layer, and an RRC layer. A DL transmission may be from the (R)AN322 to the UE 320 and a UL transmission may be from the UE 320 to the(R)AN 322. The UE 320 may further use a sidelink to communicate directlywith another UE (not shown) for D2D, P2P, and/or ProSe communication.For example, a ProSe interface may comprise one or more logicalchannels, including but not limited to a Physical Sidelink ControlChannel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a PhysicalSidelink Discovery Channel (PSDCH), and a Physical Sidelink BroadcastChannel (PSBCH).

The (R)AN 322 can include one or more access nodes, which may bereferred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), nextGeneration NodeBs (gNB), RAN nodes, controllers, transmission receptionpoints (TRPs), and so forth, and can comprise ground stations (e.g.,terrestrial access points) or satellite stations providing coveragewithin a geographic area (e.g., a cell). The (R)AN 322 may include oneor more RAN nodes for providing macrocells, picocells, femtocells, orother types of cells. A macrocell may cover a relatively largegeographic area (e.g., several kilometers in radius) and may allowunrestricted access by UEs with service subscription. A picocell maycover a relatively small geographic area and may allow unrestrictedaccess by UEs with service subscription. A femtocell may cover arelatively small geographic area (e.g., a home) and may allow restrictedaccess by UEs having an association with the femtocell (e.g., UEs in aClosed Subscriber Group (CSG), UEs for users in the home, etc.).

Although not shown, multiple RAN nodes (such as the (R)AN 322) may beused, wherein an Xn interface is defined between two or more nodes. Insome implementations, the Xn interface may include an Xn user plane(Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U mayprovide non-guaranteed delivery of user plane PDUs and support/providedata forwarding and flow control functionality. The Xn-C may providemanagement and error handling functionality, functionality to manage theXn-C interface; mobility support for the UE 320 in a connected mode(e.g., CM-CONNECTED) including functionality to manage the UE mobilityfor connected mode between one or more (R)AN nodes. The mobility supportmay include context transfer from an old (source) serving (R)AN node tonew (target) serving (R)AN node; and control of user plane tunnelsbetween old (source) serving (R)AN node to new (target) serving (R)ANnode.

The UPF 324 may act as an anchor point for intra-RAT and inter-RATmobility, an external PDU session point of interconnect to the DN 326,and a branching point to support multi-homed PDU session. The UPF 324may also perform packet routing and forwarding, packet inspection,enforce user plane part of policy rules, lawfully intercept packets (UPcollection); traffic usage reporting, perform QoS handling for userplane (e.g. packet filtering, gating, UL/DL rate enforcement), performUplink Traffic verification (e.g., SDF to QoS flow mapping), transportlevel packet marking in the uplink and downlink, and downlink packetbuffering and downlink data notification triggering. The UPF 324 mayinclude an uplink classifier to support routing traffic flows to a datanetwork. The DN 326 may represent various network operator services,Internet access, or third party services. The DN 326 may include, forexample, an application server.

FIG. 4 is a block diagram of an example UE 400 configurable according tovarious embodiments of the present disclosure, including by execution ofinstructions on a computer-readable medium that correspond to any of theexample methods and/or procedures described herein. The UE 400 comprisesone or more processor 402, transceiver 404, memory 406, user interface408, and control interface 410.

The one or more processor 402 may include, for example, an applicationprocessor, an audio digital signal processor, a central processing unit,and/or one or more baseband processors. Each of the one or moreprocessor 402 may include internal memory and/or may includeinterface(s) to communication with external memory (including the memory406). The internal or external memory can store software code, programs,and/or instructions for execution by the one or more processor 402 toconfigure and/or facilitate the UE 400 to perform various operations,including operations described herein. For example, execution of theinstructions can configure the UE 400 to communicate using one or morewired or wireless communication protocols, including one or morewireless communication protocols standardized by 3GPP such as thosecommonly known as 5G/NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, etc.,or any other current or future protocols that can be utilized inconjunction with the one or more transceiver 404, user interface 408,and/or control interface 410. As another example, the one or moreprocessor 402 may execute program code stored in the memory 406 or othermemory that corresponds to MAC, RLC, PDCP, and RRC layer protocolsstandardized by 3GPP (e.g., for NR and/or LTE). As a further example,the processor 402 may execute program code stored in the memory 406 orother memory that, together with the one or more transceiver 404,implements corresponding PHY layer protocols, such as OrthogonalFrequency Division Multiplexing (OFDM), Orthogonal Frequency DivisionMultiple Access (OFDMA), and Single-Carrier Frequency Division MultipleAccess (SC-FDMA).

The memory 406 may comprise memory area for the one or more processor402 to store variables used in protocols, configuration, control, andother functions of the UE 400, including operations corresponding to, orcomprising, any of the example methods and/or procedures describedherein. Moreover, the memory 406 may comprise non-volatile memory (e.g.,flash memory), volatile memory (e.g., static or dynamic RAM), or acombination thereof. Furthermore, the memory 406 may interface with amemory slot by which removable memory cards in one or more formats(e.g., SD Card, Memory Stick, Compact Flash, etc.) can be inserted andremoved.

The one or more transceiver 404 may include radio-frequency transmitterand/or receiver circuitry that facilitates the UE 400 to communicatewith other equipment supporting like wireless communication standardsand/or protocols. For example, the one or more transceiver 404 mayinclude switches, mixer circuitry, amplifier circuitry, filtercircuitry, and synthesizer circuitry. Such RF circuitry may include areceive signal path with circuitry to down-convert RF signals receivedfrom a front-end module (FEM) and provide baseband signals to a basebandprocessor of the one or more processor 402. The RF circuitry may alsoinclude a transmit signal path which may include circuitry to up-convertbaseband signals provided by a baseband processor and provide RF outputsignals to the FEM for transmission. The FEM may include a receivesignal path that may include circuitry configured to operate on RFsignals received from one or more antennas, amplify the received signalsand provide the amplified versions of the received signals to the RFcircuitry for further processing. The FEM may also include a transmitsignal path that may include circuitry configured to amplify signals fortransmission provided by the RF circuitry for transmission by one ormore antennas. In various embodiments, the amplification through thetransmit or receive signal paths may be done solely in the RF circuitry,solely in the FEM, or in both the RF circuitry and the FEM circuitry. Insome embodiments, the FEM circuitry may include a TX/RX switch to switchbetween transmit mode and receive mode operation.

In some exemplary embodiments, the one or more transceiver 404 includesa transmitter and a receiver that enable device 1200 to communicate withvarious 5G/NR networks according to various protocols and/or methodsproposed for standardization by 3 GPP and/or other standards bodies. Forexample, such functionality can operate cooperatively with the one ormore processor 402 to implement a PHY layer based on OFDM, OFDMA, and/orSC-FDMA technologies, such as described herein with respect to otherfigures.

The user interface 408 may take various forms depending on particularembodiments, or can be absent from the UE 400. In some embodiments, theuser interface 408 includes a microphone, a loudspeaker, slidablebuttons, depressible buttons, a display, a touchscreen display, amechanical or virtual keypad, a mechanical or virtual keyboard, and/orany other user-interface features commonly found on mobile phones. Inother embodiments, the UE 400 may comprise a tablet computing deviceincluding a larger touchscreen display. In such embodiments, one or moreof the mechanical features of the user interface 408 may be replaced bycomparable or functionally equivalent virtual user interface features(e.g., virtual keypad, virtual buttons, etc.) implemented using thetouchscreen display, as familiar to persons of ordinary skill in theart. In other embodiments, the UE 400 may be a digital computing device,such as a laptop computer, desktop computer, workstation, etc. thatcomprises a mechanical keyboard that can be integrated, detached, ordetachable depending on the particular exemplary embodiment. Such adigital computing device can also comprise a touch screen display. Manyexample embodiments of the UE 400 having a touch screen display arecapable of receiving user inputs, such as inputs related to exemplarymethods and/or procedures described herein or otherwise known to personsof ordinary skill in the art.

In some exemplary embodiments of the present disclosure, the UE 400 mayinclude an orientation sensor, which can be used in various ways byfeatures and functions of the UE 400. For example, the UE 400 can useoutputs of the orientation sensor to determine when a user has changedthe physical orientation of the UE 400′s touch screen display. Anindication signal from the orientation sensor can be available to anyapplication program executing on the UE 400, such that an applicationprogram can change the orientation of a screen display (e.g., fromportrait to landscape) automatically when the indication signalindicates an approximate 90-degree change in physical orientation of thedevice. In this manner, the application program can maintain the screendisplay in a manner that is readable by the user, regardless of thephysical orientation of the device. In addition, the output of theorientation sensor can be used in conjunction with various exemplaryembodiments of the present disclosure.

The control interface 410 may take various forms depending on particularembodiments. For example, the control interface 410 may include anRS-232 interface, an RS-485 interface, a USB interface, an HDMIinterface, a Bluetooth interface, an IEEE (“Firewire”) interface, an I²Cinterface, a PCMCIA interface, or the like. In some exemplaryembodiments of the present disclosure, control interface 1260 cancomprise an IEEE 802.3 Ethernet interface such as described above. Insome embodiments of the present disclosure, the control interface 410may include analog interface circuitry including, for example, one ormore digital-to-analog (D/A) and/or analog-to-digital (A/D) converters.

Persons of ordinary skill in the art can recognize the above list offeatures, interfaces, and radio-frequency communication standards ismerely exemplary, and not limiting to the scope of the presentdisclosure. In other words, the UE 400 may include more functionalitythan is shown in FIG. 4 including, for example, a video and/orstill-image camera, microphone, media player and/or recorder, etc.Moreover, the one or more transceiver 404 may include circuitry forcommunication using additional radio-frequency communication standardsincluding Bluetooth, GPS, and/or others. Moreover, the one or moreprocessor 402 may execute software code stored in the memory 406 tocontrol such additional functionality. For example, directional velocityand/or position estimates output from a GPS receiver can be available toany application program executing on the UE 400, including variousexemplary methods and/or computer-readable media according to variousexemplary embodiments of the present disclosure.

FIG. 5 is a block diagram of an example network node 500 configurableaccording to various embodiments of the present disclosure, including byexecution of instructions on a computer-readable medium that correspondto any of the example methods and/or procedures described herein.

The network node 500 includes a one or more processor 502, a radionetwork interface 504, a memory 506, a core network interface 508, andother interfaces 510. The network node 500 may comprise, for example, abase station, eNB, gNB, access node, or component thereof.

The one or more processor 502 may include any type of processor orprocessing circuitry and may be configured to perform an of the methodsor procedures disclosed herein. The memory 506 may store software code,programs, and/or instructions executed by the one or more processor 502to configure the network node 500 to perform various operations,including operations described herein. For example, execution of suchstored instructions can configure the network node 500 to communicatewith one or more other devices using protocols according to variousembodiments of the present disclosure, including one or more methodsand/or procedures discussed above. Furthermore, execution of such storedinstructions can also configure and/or facilitate the network node 500to communicate with one or more other devices using other protocols orprotocol layers, such as one or more of the PHY, MAC, RLC, PDCP, and RRClayer protocols standardized by 3GPP for LTE, LTE-A, and/or NR, or anyother higher-layer protocols utilized in conjunction with the radionetwork interface 504 and the core network interface 508. By way ofexample and without limitation, the core network interface 508 comprisean S1 interface and the radio network interface 504 may comprise a Uuinterface, as standardized by 3GPP. The memory 506 may also storevariables used in protocols, configuration, control, and other functionsof the network node 500. As such, the memory 506 may comprisenon-volatile memory (e.g., flash memory, hard disk, etc.), volatilememory (e.g., static or dynamic RAM), network-based (e.g., “cloud”)storage, or a combination thereof.

The radio network interface 504 may include transmitters, receivers,signal processors, ASICs, antennas, beamforming units, and othercircuitry that enables network node 500 to communicate with otherequipment such as, in some embodiments, a plurality of compatible userequipment (UE). In some embodiments, the network node 500 may includevarious protocols or protocol layers, such as the PHY, MAC, RLC, PDCP,and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and/or5G/NR. According to further embodiments of the present disclosure, theradio network interface 504 may include a PHY layer based on OFDM,OFDMA, and/or SC-FDMA technologies. In some embodiments, thefunctionality of such a PHY layer can be provided cooperatively by theradio network interface 504 and the one or more processor 502.

The core network interface 508 may include transmitters, receivers, andother circuitry that enables the network node 500 to communicate withother equipment in a core network such as, in some embodiments,circuit-switched (CS) and/or packet-switched Core (PS) networks. In someembodiments, the core network interface 508 may include the S1 interfacestandardized by 3GPP. In some embodiments, the core network interface508 may include one or more interfaces to one or more SGWs, MMEs, SGSNs,GGSNs, and other physical devices that comprise functionality found inGERAN, UTRAN, E-UTRAN, and CDMA2000 core networks that are known topersons of ordinary skill in the art. In some embodiments, these one ormore interfaces may be multiplexed together on a single physicalinterface. In some embodiments, lower layers of the core networkinterface 508 may include one or more of asynchronous transfer mode(ATM), Internet Protocol (IP)-over-Ethernet, SDH over optical fiber,T1/E1/PDH over a copper wire, microwave radio, or other wired orwireless transmission technologies known to those of ordinary skill inthe art.

The other interfaces 510 may include transmitters, receivers, and othercircuitry that enables the network node 500 to communicate with externalnetworks, computers, databases, and the like for purposes of operations,administration, and maintenance of the network node 500 or other networkequipment operably connected thereto.

It is well understood that the use of personally identifiableinformation should follow privacy policies and practices that aregenerally recognized as meeting or exceeding industry or governmentalrequirements for maintaining the privacy of users. In particular,personally identifiable information data should be managed and handledso as to minimize risks of unintentional or unauthorized access or use,and the nature of authorized use should be clearly indicated to users.

For one or more embodiments, at least one of the components set forth inone or more of the preceding figures may be configured to perform one ormore operations, techniques, processes, and/or methods as set forth inthe Example Section below. For example, the baseband circuitry asdescribed above in connection with one or more of the preceding figuresmay be configured to operate in accordance with one or more of theexamples set forth below. For another example, circuitry associated witha UE, base station, network element, etc. as described above inconnection with one or more of the preceding figures may be configuredto operate in accordance with one or more of the examples set forthbelow in the example section.

EXAMPLE SECTION

The following examples pertain to further embodiments.

Example 1 is a method of a user equipment (UE), comprising: receiving afirst authentication request in response to a first triggering requestfrom the UE to a mobility management node of a first Tracking Area (TA)in which the UE is located; preparing and storing an authenticationresponse according to the first authentication request; in response todetermining that the UE has moved from the first TA to a second TA:aborting a sending of the authentication response; aborting the firsttriggering request; sending a second triggering request from the UE to amobility management node of the second TA; receiving, from the mobilitymanagement node of the second TA; a second authentication request inresponse to the second triggering request; and sending the storedauthentication response according to the first authentication request tothe mobility management node of the second TA in response to the receiptof the second authentication request and in further response to adetermination that a given parameter of each of the first and secondauthentication requests are the same.

Example 2 is the method of Example 1, wherein the given parameter is aRAND parameter.

Example 3 is the method of any of Examples 1-2, wherein the firstauthentication request and the second authentication request arereceived according to different Key Set Identifiers (KSIs).

Example 4 is the method of any of Examples 1-3, wherein the mobilitymanagement node of the first TA and the mobility management node of thesecond TA are the same mobility management node.

Example 5 is a method of a user equipment (UE), comprising: receiving afirst authentication request in response to a first triggering requestfrom the UE to a mobility management node of a first Tracking Area (TA)in which the UE is located; in response to determining that the UE hasmoved from the first TA to a second TA: aborting a sending of a firstauthentication response; aborting the first triggering request; sendinga second triggering request from the UE to a mobility management node ofthe second TA; receiving, from the mobility management node of thesecond TA, a second authentication request in response to the secondtriggering request; and sending a second authentication responseaccording to the second authentication request to the mobilitymanagement node of the second TA in response to the receipt of thesecond authentication request.

Example 6 is the method of Example 5, wherein the second authenticationresponse is sent in further response to a determination that a givenparameter of each of the first and second authentication requests aredifferent.

Example 7 is the method of any of Examples 5-6, wherein the firstauthentication request and the second authentication request arereceived according to different Key Set Identifiers (KSIs).

Example 8 is the method of any of Examples 5-7, wherein the mobilitymanagement node of the first TA and the mobility management node of thesecond TA are the same mobility management node.

Example 9 is a computing apparatus of a user equipment (UE), thecomputing apparatus comprising a processor and memory storinginstructions. The processor and the memory storing instructions that,when executed by the processor, configure the computing apparatus to:process a first authentication request received at the UE in response toa first triggering request from the UE to a mobility management node ofa first Tracking Area (TA) in which the UE is located; prepare and storean authentication response according to the first authenticationrequest; in response to determining that the UE has moved from the firstTA to a second TA: abort a sending of the authentication response; abortthe first triggering request; prepare a second triggering request to besent from the UE to a mobility management node of the second TA; processa second authentication request received at the UE from the mobilitymanagement node of the second TA in response to the second triggeringrequest; and retrieve the stored authentication response according tothe first authentication request, the stored authentication response tobe sent by the UE to the mobility management node of the second TA inresponse to the receipt at the UE of the second authentication requestand in further response to a determination that a given parameter ofeach of the first and second authentication requests are the same.

Example 10 is the computing apparatus of Example 9, wherein the givenparameter is a RAND parameter.

Example 11 is the computing apparatus of any of Examples 9-10, whereinthe first authentication request and the second authentication requestare received according to different Key Set Identifiers (KSIs).

Example 12 is the computing apparatus of any of Examples 9-11, whereinthe mobility management node of the first TA and the mobility managementnode of the second TA are the same mobility management node.

Example 13 is a computing apparatus of a user equipment (UE), thecomputing apparatus comprising a processor and a memory storinginstructions. The processor and the memory storing instructions that,when executed by the processor, configure the computing apparatus to:process a first authentication request received at the UE in response toa first triggering request from the UE to a mobility management node ofa first Tracking Area (TA) in which the UE is located; in response todetermining that the UE has moved from the first TA to a second TA:abort a sending of a first authentication response; abort the firsttriggering request; prepare a second triggering request to be sent fromthe UE to a mobility management node of the second TA; process a secondauthentication request received at the UE from the mobility managementnode of the second TA in response to the second triggering request; andprepare a second authentication response according to the secondauthentication request, the second authentication response to be sent bythe UE to the mobility management node of the second TA in response tothe receipt of the second authentication request.

Example 14 is the computing apparatus of Example 13, wherein the secondauthentication response is sent in further response to a determinationthat a given parameter of each of the first and second authenticationrequests are different.

Example 15 is the computing apparatus of any of Examples 13-14, whereinthe first authentication request and the second authentication requestare received according to different Key Set Identifiers (KSIs).

Example 16 is the computing apparatus of any of Examples 13-15, whereinthe mobility management node of the first TA and the mobility managementnode of the second TA are the same mobility management node.

Example 17 is a non-transitory computer-readable storage medium, thecomputer-readable storage medium including instructions that whenexecuted by a computer, cause the computer to: process a firstauthentication request received at a UE in response to a firsttriggering request from the UE to a mobility management node of a firstTracking Area (TA) in which the UE is located; prepare and store anauthentication response according to the first authentication request;in response to determining that the UE has moved from the first TA to asecond TA: abort a sending of the authentication response; abort thefirst triggering request; prepare a second triggering request to be sentfrom the UE to a mobility management node of the second TA; process asecond authentication request received at the UE from the mobilitymanagement node of the second TA in response to the second triggeringrequest; and retrieve the stored authentication response according tothe first authentication request, the stored authentication response tobe sent by the UE to the mobility management node of the second TA inresponse to the receipt at the UE of the second authentication requestand in further response to a determination that a given parameter ofeach of the first and second authentication requests are the same.

Example 18 is the non-transitory computer-readable storage medium ofExample 17, wherein the given parameter is a RAND parameter.

Example 19 is the non-transitory computer-readable storage medium of anyof Examples 17-18, wherein the first authentication request and thesecond authentication request are received according to different KeySet Identifiers (KSIs).

Example 20 is the non-transitory computer-readable storage medium of anyof Examples 17-19, wherein the mobility management node of the first TAand the mobility management node of the second TA are the same mobilitymanagement node.

Example 21 is a non-transitory computer-readable storage medium, thecomputer-readable storage medium including instructions that whenexecuted by a computer, cause the computer to: process a firstauthentication request received at a UE in response to a firsttriggering request from the UE to a mobility management node of a firstTracking Area (TA) in which the UE is located; in response todetermining that the UE has moved from the first TA to a second TA:abort a sending of a first authentication response; abort the firsttriggering request; prepare a second triggering request to be sent fromthe UE to a mobility management node of the second TA; process a secondauthentication request received at the UE from the mobility managementnode of the second TA in response to the second triggering request; andprepare a second authentication response according to the secondauthentication request, the second authentication response to be sent bythe UE to the mobility management node of the second TA in response tothe receipt of the second authentication request.

Example 22 is the non-transitory computer-readable storage medium ofExample 21, wherein the second authentication response is sent infurther response to a determination that a given parameter of each ofthe first and second authentication requests are different.

Example 23 is the non-transitory computer-readable storage medium of anyof Examples 21-22, wherein the first authentication request and thesecond authentication request are received according to different KeySet Identifiers (KSIs).

Example 24 is the non-transitory computer-readable storage medium of anyof Examples 21-23, wherein the mobility management node of the first TAand the mobility management node of the second TA are the same mobilitymanagement node.

Example 25 may include an apparatus comprising means to perform one ormore elements of a method described in or related to any of the aboveExamples, or any other method or process described herein.

Example 26 may include one or more non-transitory computer-readablemedia comprising instructions to cause an electronic device, uponexecution of the instructions by one or more processors of theelectronic device, to perform one or more elements of a method describedin or related to any of the above Examples, or any other method orprocess described herein.

Example 27 may include an apparatus comprising logic, modules, orcircuitry to perform one or more elements of a method described in orrelated to any of the above Examples, or any other method or processdescribed herein.

Example 28 may include a method, technique, or process as described inor related to any of the above Examples, or portions or parts thereof.

Example 29 may include an apparatus comprising: one or more processorsand one or more computer-readable media comprising instructions that,when executed by the one or more processors, cause the one or moreprocessors to perform the method, techniques, or process as described inor related to any of the above Examples, or portions thereof

Example 30 may include a signal as described in or related to any of theabove Examples, or portions or parts thereof.

Example 31 may include a datagram, packet, frame, segment, protocol dataunit (PDU), or message as described in or related to any of the aboveExamples, or portions or parts thereof, or otherwise described in thepresent disclosure.

Example 32 may include a signal encoded with data as described in orrelated to any of the above Examples, or portions or parts thereof, orotherwise described in the present disclosure.

Example 33 may include a signal encoded with a datagram, packet, frame,segment, PDU, or message as described in or related to any of the aboveExamples, or portions or parts thereof, or otherwise described in thepresent disclosure.

Example 34 may include an electromagnetic signal carryingcomputer-readable instructions, wherein execution of thecomputer-readable instructions by one or more processors is to cause theone or more processors to perform the method, techniques, or process asdescribed in or related to any of the above Examples, or portionsthereof.

Example 35 may include a computer program comprising instructions,wherein execution of the program by a processing element is to cause theprocessing element to carry out the method, techniques, or process asdescribed in or related to any of the above Examples, or portionsthereof.

Example 36 may include a signal in a wireless network as shown anddescribed herein.

Example 37 may include a method of communicating in a wireless networkas shown and described herein.

Example 38 may include a system for providing wireless communication asshown and described herein.

Example 39 may include a device for providing wireless communication asshown and described herein.

Any of the above described examples may be combined with any otherexample (or combination of examples), unless explicitly statedotherwise. The foregoing description of one or more implementationsprovides illustration and description, but is not intended to beexhaustive or to limit the scope of embodiments to the precise formdisclosed. Modifications and variations are possible in light of theabove teachings or may be acquired from practice of various embodiments.

Embodiments and implementations of the systems and methods describedherein may include various operations, which may be embodied inmachine-executable instructions to be executed by a computer system. Acomputer system may include one or more general-purpose orspecial-purpose computers (or other electronic devices). The computersystem may include hardware components that include specific logic forperforming the operations or may include a combination of hardware,software, and/or firmware.

It should be recognized that the systems described herein includedescriptions of specific embodiments. These embodiments can be combinedinto single systems, partially combined into other systems, split intomultiple systems or divided or combined in other ways. In addition, itis contemplated that parameters, attributes, aspects, etc. of oneembodiment can be used in another embodiment. The parameters,attributes, aspects, etc. are merely described in one or moreembodiments for clarity, and it is recognized that the parameters,attributes, aspects, etc. can be combined with or substituted forparameters, attributes, aspects, etc. of another embodiment unlessspecifically disclaimed herein.

Although the foregoing has been described in some detail for purposes ofclarity, it will be apparent that certain changes and modifications maybe made without departing from the principles thereof. It should benoted that there are many alternative ways of implementing both theprocesses and apparatuses described herein. Accordingly, the presentembodiments are to be considered illustrative and not restrictive, andthe description is not to be limited to the details given herein, butmay be modified within the scope and equivalents of the appended claims.

1. A method of a user equipment (UE), comprising: receiving a firstauthentication request in response to a first triggering request fromthe UE to a mobility management node of a first Tracking Area (TA) inwhich the UE is located; preparing and storing an authenticationresponse according to the first authentication request; in response todetermining that the UE has moved from the first TA to a second TA:aborting a sending of the authentication response; aborting the firsttriggering request; sending a second triggering request from the UE to amobility management node of the second TA; receiving, from the mobilitymanagement node of the second TA, a second authentication request inresponse to the second triggering request; and sending the storedauthentication response according to the first authentication request tothe mobility management node of the second TA in response to thereceiving of the second authentication request and in further responseto a determination that a given parameter of each of the first andsecond authentication requests are the same.
 2. The method of claim 1,wherein the given parameter is a RAND parameter.
 3. The method of claim1, wherein the first authentication request and the secondauthentication request are received according to different Key SetIdentifiers (KSIs).
 4. The method of claim 1, wherein the mobilitymanagement node of the first TA and the mobility management node of thesecond TA are the same mobility management node.
 5. A method of a userequipment (UE), comprising: receiving a first authentication request inresponse to a first triggering request from the UE to a mobilitymanagement node of a first Tracking Area (TA) in which the UE islocated; in response to determining that the UE has moved from the firstTA to a second TA: aborting a sending of a first authenticationresponse; aborting the first triggering request; sending a secondtriggering request from the UE to a mobility management node of thesecond TA; receiving, from the mobility management node of the secondTA, a second authentication request in response to the second triggeringrequest; and sending a second authentication response according to thesecond authentication request to the mobility management node of thesecond TA in response to the receiving of the second authenticationrequest.
 6. The method of claim 5, wherein the second authenticationresponse is sent in further response to a determination that a givenparameter of each of the first and second authentication requests aredifferent.
 7. The method of claim 5, wherein the first authenticationrequest and the second authentication request are received according todifferent Key Set Identifiers (KSIs).
 8. The method of claim 5, whereinthe mobility management node of the first TA and the mobility managementnode of the second TA are the same mobility management node.
 9. Acomputing apparatus of a user equipment (UE), the computing apparatuscomprising: a processor; and a memory storing instructions that, whenexecuted by the processor, configure the computing apparatus to: processa first authentication request received at the UE in response to a firsttriggering request from the UE to a mobility management node of a firstTracking Area (TA) in which the UE is located; prepare and store anauthentication response according to the first authentication request;in response to determining that the UE has moved from the first TA to asecond TA: abort a sending of the authentication response; abort thefirst triggering request; prepare a second triggering request to be sentfrom the UE to a mobility management node of the second TA; process asecond authentication request received at the UE from the mobilitymanagement node of the second TA in response to the second triggeringrequest; and retrieve the stored authentication response according tothe first authentication request, the stored authentication response tobe sent by the UE to the mobility management node of the second TA inresponse to the second authentication request and in further response toa determination that a given parameter of each of the first and secondauthentication requests are the same.
 10. The computing apparatus ofclaim 9, wherein the given parameter is a RAND parameter.
 11. Thecomputing apparatus of claim 9, wherein the first authentication requestand the second authentication request are received according todifferent Key Set Identifiers (KSIs).
 12. The computing apparatus ofclaim 9, wherein the mobility management node of the first TA and themobility management node of the second TA are the same mobilitymanagement node. 13-24. (canceled)